Local solid state drive (SSD) caching can be used for secondary caching in storage architectures. Secondary caching devices in these configurations are typically redundant in order to reliably cache “dirty” data (e.g., data in a secondary cache that does reflect the contents of primary storage). When a redundant drive fails, however, a rebuild operation of the redundant drives can be complex and time consuming, because the same device can be caching data for different source Virtual Drives (VDs). An SSD volume may be rebuilt relatively easily offline with no background input/output (10) being executed. However, this technique requires keeping the IO system offline for an extended time and is not suited for practical use cases that involve mission critical data, always ‘on’ systems, and so forth. A technique to avoid rebuild is to remove dirty data (e.g., flush dirty data from SSD cache to primary storage) from a surviving drive so that the data is not exchanged for rebuild. Once the dirty data has been removed (flushed), redundant storage of dirty data can be performed for subsequent write IOs. However, with SSDs having large storage capacities (e.g., on the order of terabytes of data), flushing dirty data to disk is highly time consuming and detrimental to performance, since a WRITE cache (dirty data generation) cannot restart unless the entirety of the dirty data is flushed to disk. This can be especially problematic in configurations where data is mirrored across multiple servers, e.g., where the entire dirty cache needs to be flushed every time a server is rebooted, even when a mirrored drive is absent from the storage system for only a small amount of time (as the corresponding server is rebooted).